深入学习 Redis 原理 - 持久化

发表于 | 分类于

RDB

在指定的时间间隔能对你的数据进行快照存储。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# 时间策略
# 要禁用RDB配置，只需要在save的最后一行写上：save ""
# 表示900s内如果有1条是写入命令，就触发产生一次快照，可以理解为就进行一次备份
save 900 1 
save 300 10
save 60 10000

# 文件名称
dbfilename dump.rdb

# 文件保存路径
dir /home/work/app/redis/data/

# 如果持久化出错，主进程是否停止写入
# 这是当备份进程出错时，主进程就停止接受新的写入操作，是为了保护持久化的数据一致性问题。
# 如果自己的业务有完善的监控系统，可以禁止此项配置，否则请开启。
stop-writes-on-bgsave-error yes

# 是否压缩
rdbcompression yes

# 导入时是否检查
# 建议没有必要开启，毕竟Redis本身就属于CPU密集型服务器，再开启压缩会带来更多的CPU消耗，相比硬盘成本，CPU更值钱。
rdbchecksum yes

触发条件

  1. 手动触发：
  • save：会阻塞当前Redis服务器，直到持久化完成，线上应该禁止使用。
  • bgsave：该触发方式会fork一个子进程，由子进程负责持久化过程，因此阻塞只会发生在fork子进程的时候。
  1. 自动触发：
  • 根据 save m n 配置规则自动触发；
  • 从节点全量复制时，主节点发送rdb文件给从节点完成复制操作，主节点会触发 bgsave；
  • 执行 debug reload 时；
  • 执行 shutdown时，如果没有开启aof，也会触发。

AOF

记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
# 是否开启aof
appendonly yes

# 文件名称
appendfilename "appendonly.aof"

# 同步方式
# always：把每个写命令都立即同步到aof，很慢，但是很安全
# everysec：每秒同步一次，是折中方案
# no：redis不处理交给OS来处理，非常快，但是也最不安全
# 一般情况下都采用 everysec 配置，这样可以兼顾速度与安全，最多损失1s的数据。
appendfsync everysec

# aof重写期间是否同步
no-appendfsync-on-rewrite no

# 重写触发配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# 加载aof时如果有错如何处理
aof-load-truncated yes

# 文件重写策略
aof-rewrite-incremental-fsync yes

处理流程

  1. 命令的实时写入：命令写入 -> 追加到aof的buffer -> 同步到磁盘。
  2. AOF文件的重写。

触发条件

  1. 手动触发：
  • bgrewriteaof
  1. 自动触发

定时任务机制

定时任务执行的频率可以在配置文件中通过 hz 10 来设置（这个配置表示1s内执行10次，也就是每100ms触发一次定时任务）。

该值最大能够设置为：500，但是不建议超过：100，因为值越大说明执行频率越频繁越高，这会带来CPU的更多消耗，从而影响主进程读写性能。

定时任务使用的是Redis自己实现的 TimeEvent，它会定时去调用一些命令完成定时任务，这些任务可能会阻塞主进程导致Redis性能下降。因此我们在配置Redis时，一定要整体考虑一些会触发定时任务的配置，根据实际情况进行调整。

Reference